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Abstract — With the advent of faster, cheaper and better 
missions, NASA Projects acknowledged that a higher level 
of risk was inherent and accepted with this approach. It was 
incumbent however upon each component of the Project 
whether spacecraft, payload, launch vehicle or ground data 
system to ensure that the mission would nevertheless be an 
unqualified success. 

The Small Explorer (SMEX) program’s ground data system 
(GDS) team developed risk mitigation techniques to achieve 
these goals starting in 1989. These techniques have evolved 
through the SMEX series of missions and are practiced 
today under the Triana program. These techniques are: 

1 . Mission Team Organization - empowerment of a close- 
knit ground data system team comprising system 
engineering, software engineering, testing, and flight 
operations personnel, 

2. Common Spacecraft Test & Operational Control System 

- utilization of the pre-launch spacecraft integration 
system as the post-launch ground data system on-orbit 
command and control system, 

3. Utilization of operations personnel in pre-launch testing 

- making the flight operations team an integrated 
member of the spacecraft testing activities at the 
beginning of the spacecraft fabrication phase, 

4. Consolidated Test Team - combined system, mission 
readiness and operations testing to optimize test 
opportunities with the ground system and spacecraft, 
and 

5. Reuse of Spacecraft , Systems and People - reuse of 
people, software and on-orbit spacecraft throughout the 
SMEX mission series. 

The SMEX ground system development approach for faster, 
cheaper, better missions has been very successful. This 
paper will discuss these risk management techniques in the 
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areas of ground data system design, implementation, test and 
operational readiness. 
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1. Introduction 

The normal practice for developing a GDS for a mission 
operated at the Goddard Space Flight Center (GSFC) in the 
1980*s utilized a development team and a flight operations 
team, both of which were organizationally independent of 
each other. In addition, they were independent of the Project 
team responsible for building and launching the satellite. 
All three groups interacted and coordinated common 
activities, but this interaction required close coordination, 
detailed documentation, frequent meetings and extensive 
testing. 

The spacecraft architecture and design of hardware and 
software components varied from mission to mission with 
little commonality for the interfaces to the operational GDS. 

Multi-mission institutional systems consisting of hundreds of 
thousands of lines of code were modified to accommodate 
the next mission. These modifications were expensive to 
implement and test. Retesting of existing operational 
missions was another burden on this approach. However, the 
state and cost of computer technology at this time made this 
the only viable approach. 
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Prior to the advent of the faster, cheaper, better approach to 
NASA missions, the schedules for GDS implementation 
were nominally five years or more. In 1989 NASA identified 
a new Explorer-class program at GSFC that changed the 
way future missions and the associated GDS would be 
constructed, scheduled and budgeted. Now GDS 
development schedules were only three years in duration. 
The GDS had to drastically modify its approach to 
implementation and testing to support launch and on-orbit 
operations. The following discussion topics cover how we 
responded to these new challenges. 

2. The SMEX Era 

The SMEX Project charter was to provide frequent flight 
opportunities at three-year intervals, from NASA approval 
to launch. Higher risk to the mission, in exchange for these 
more frequent flight opportunities, was deemed acceptable. 


experience and took advantage of changes internally and 
externally. 

The SMEX Project, coupled with advances in computer 
workstation technology, provided GSFC with a new 
opportunity to build ground systems faster, while being 
more reliable and less expensive. Given the charter of 
frequent flight opportunities and capped costs, there was no 
choice. Although higher risks were deemed acceptable, 
mission success remained paramount and delays in 
completing the GDS were not permitted to impact the 
spacecraft launch schedule. 

Two important advantages to SMEX GDS development 
activities occurred outside the control of the GDS 
organization team. These were the reuse of the spacecraft 
architecture and the proximity of the spacecraft vendor to 
the GDS team. 


The first missions selected for this new program were the 
Solar Anomalous and Magnetospheric Particle Explorer 
(SAMPEX), the Submillimeter Wave Astronomy Satellite 
(SWAS), and the Fast Auroral Snapshot Explorer (FAST). 
The original launch dates for these missions were SAMPEX 
in mid- 1992, SWAS in mid- 1993, and FAST in late 1993 
[1]. 

In 1995, the next two missions were identified: the 
Transition Region and Coronal Explorer (TRACE) and the 
Wide-Field Infrared Explorer (WIRE). TRACE was 
scheduled for launch in 1998 and WIRE in 1999. Figure 1 
depicts the original implementation schedule and operational 
life of each of these missions. 
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Figure 1. SMEX Mission Set 1 & 2 Schedules 

Meeting the challenge of concurrent, compact mission 
schedules required innovations in GDS development and 
operational preparedness. However, not all these risk 
mitigation approaches were applied on day one. These 
approaches evolved over time as the GDS team gained 


Similar spacecraft architectures 

The first five spacecraft were designed and constructed by 
the same GSFC organization and followed similar 
implementation standards. The telemetry and command 
protocols used onboard the satellites adopted the 
Consultative Committee for Space Data Systems (CCSDS) 
standard. As a result interfaces were very similar between 
each GDS, more so than with previous missions. 

Location of spacecraft and GDS development activities 

Typically GSFC projects used a private contractor to build 
the spacecraft offsite and then deliver it to GSFC for several 
months of integration testing. Upon completion of 
integration testing, the spacecraft was shipped to the launch 
site. Under the SMEX program, the spacecraft was 
constructed on the GSFC campus making technical 
interaction between the two groups an almost daily 
occurrence over a two to three year period. 

3. Risk Mitigation Techniques 

In addition to the spacecraft architecture and location 
aspects of the SMEX Project, there were several GDS-based 
initiatives that improved the chances to meet the SMEX 
goals of cost and schedule while not compromising mission 
success. 

These initiatives or risk mitigation techniques were: 1). 
empowerment of a close-knit ground data system team 
comprising system engineering, software engineering, 
testing, and flight operations personnel, 2). utilization of the 
pre-launch spacecraft integration and test (I&T) system as 
the post-launch ground data system on-orbit command and 
control system, 3). utilization of flight operations personnel 
in pre-launch spacecraft testing activities, 4). combined 
system, mission readiness and operations testing to optimize 
test opportunities with the ground system and spacecraft, and 
5). 



reuse of people, software and on-orbit spacecraft throughout 
the SMEX and Triana mission series. 

This section will discuss these initiatives in terms of their 
ability to mitigate risks in the GDS in an environment of 
faster, cheaper and better missions. 

/. Mission Team Organization 

The SMEX GDS mission team, comprised of both 
contractors and civil servants, was responsible for the 
implementation and on-orbit operation of the GDS. The 
team was led by the Ground System Project Manager 
(GSPM). The GSPM was responsible for both the 
development of the GDS and its operation for the first 30 
days of the on-orbit mission phase. Under the GSPM, the 
Implementation Manager (IM) was responsible for system 
engineering, software development and test efforts. Figure 2 
presents the SMEX mission team organization. 



Figure 2. SMEX Mission Team Organization 

The team developed GDS requirements as a unit, so the 
implementation was as efficient and cost effective as 
possible. Each member of the team was empowered to 
represent his or her discipline, regardless of “badge”. They 
were each accountable for their deliveries, action items, and 
test schedule. They were encouraged to take ownership of 
the entire mission, with each part contributing to the success 
of the end-to-end system. The creed was “ it is our mission”. 
This mission team also was its’ own configuration control 
board. Each potential change to the implementation of a 
particular set of requirements would have to pass a rigorous 
audit by the other members of the team, since each element 
change may impact another element within the data system. 
The IM would make the final decision with team input. 

When identifying the many ways to implement a 
requirement, the mission team would discuss the risk factors 
of each option. Through trade studies or previous experience 
with that particular option, a plan would take shape. Then, 
this plan would be discussed amongst all involved on both 
the space and ground segments of the project, and the plan 
would be agreed to or altered accordingly. On occasion, 
there would be only one way to implement a requirement. 


Then, rigorous testing would be the mitigating factor for risk 
analysis. 

The team included ad-hoc members representing the science 
team, the spacecraft element, or the tracking services, which 
would participate on an infrequent basis depending on where 
the project was in the development cycle. 

Other splinter working groups were formed as needed (i.e. 
RF working group, mission readiness testing group) to focus 
on particular issues or problems that affected a portion of 
the implementation team. These splinter groups would be 
assigned a chair, issue and track actions, and report back to 
the mission team where those actions would also be tracked 
until closed. Additionally, the GSPM would organize a 
Project wide retreat, where representatives from every 
element within the ground data system, spacecraft and 
instrument team would gather for 3-4 days. During this 
retreat, there would be presentations or tutorials to each 
other, informal requirement reviews, splinter working 
groups and the resolution of issues between elements. These 
workshops/retreats served as tremendous team building 
tools, while at the same time achieving significant results in 
closing issues sometimes 6 months earlier than normal. 

Each mission team element lead engineer contributed 
significantly to the production of materials for presentation 
at major reviews, and while they may not actually stand and 
present; their input was sanctioned by the managers 
responsible for that particular discipline. By getting 
everyone on the team involved and assuming ownership and 
responsibility for the success of the entire system, you have 
synergy. It’s not just the job of a single person, or the 
manager to apply risk management - it’s everyone’s 
responsibility. 

At the conclusion of the launch phase of each mission, the 
mission team would re-convene and discuss lessons learned. 
What went right? What could have been done better? In a 
short, 3 -year development cycle, these lessons learned can 
be immediately applied to the next mission in the queue, 
although most likely, it’s already underway. 

2. Common Spacecraft Test & Operational Control System 

The Integrated Test and Operations System (ITOS) is a set 
of equipment that is used initially to interface with the 
spacecraft from the box level, all the way through to the 
observatory level. Along the way, the ITOS will add 
capabilities that the control center will utilize for command 
and control of the spacecraft when it is transferred to the 
Flight Operations Team on orbit. Using a common ground 
system for both I&T and operations allows for an operations 
system to be launch capable much earlier than on previous 
missions [2]. The ITOS will have a factor of 10 more hours 
of test time with the spacecraft under this approach than on 
previous, operations-unique ground data systems. Also, 
combining the two systems bridges the gap between the 







space and ground segments on a typical mission. This is a 
tremendous team building technique. 

By using a similar ground system during spacecraft I&T and 
mission operations, problems are detected earlier. Earlier 
detection allows cleaner releases for the ground data system 
team. Another benefit for using the same ground system is 
that the development team is aware of mission requirements. 
The development team agrees to mission requirements and 
can apply this knowledge to program patches and 
enhancements. 

There has always been a race to have all spacecraft 
procedures including contingencies tested prior to launch. 
When SMEX had two different ground systems, most 
procedures were tested in the last month and large amounts 
of time had to be taken away from spacecraft I&T testing to 
ensure that all procedures were verified against the actual 
spacecraft. Risk was reduced when SMEX decided to use a 
common system for spacecraft I&T and operations because 
operation procedures would have more test time available. 
Most of the procedures were developed for I&T and reused 
in operations, and it reduced the need to dedicate spacecraft 
I&T time for procedure testing for the operations team. The 
decision to use a common ground system enabled the 
operations team to play a larger role in the spacecraft I&T 
test and development areas. 

3. Utilization of Operations Team in Pre-Launch Testing 

In addition to leveraging the spacecraft I&T system, for on- 
orbit operations, the people responsible for operating the 
spacecraft on-orbit became key partners in the test and 
checkout of the spacecraft and payloads. It enabled the 
operations team to gain greater access to the spacecraft. This 
access is beneficial for performing testing and validating 
operations concepts. Greater access to the spacecraft 
transforms into knowledge and experience for the operations 
team reducing risk throughout the mission life. 



Figure 3. Spacecraft Access Benefit 
Spacecraft access translated into greater spacecraft 
knowledge for the operations team. By performing testing 
during spacecraft I&T, the operations team gained a better 
understanding of the spacecraft systems and instruments for 


the mission. Over time, the project looked at the test 
conductors as another set of system engineers monitoring the 
spacecraft development and testing. This gave the Project 
system engineers a higher confidence level during spacecraft 
I&T and throughout the mission. A better trained and more 
knowledgable operations team reduced mission risk 
significantly during the operational phase of the mission. By 
participating in the spacecraft development and testing of the 
spacecraft, the operations team had the added knowledge of 
previous spacecraft anomalies found during I&T. The 
operations team had better insight into which telemetry 
points to trend and monitor and it built a better relationship 
between the operations team and spacecraft engineers. The 
operations team had better access to the spacecraft engineers 
for the operational phase of the mission due to the working 
relationship developed during spacecraft I&T. 

The operations team gained experience by performing 
spacecraft I&T testing. The operations team was tasked to 
stress test the spacecraft and ground system. This provided 
benefits to the development team and operations team, and 
reduced risk by minimizing the unknown perfromance 
characteristics of the spacecraft. 

The experience gained during testing was transitioned to the 
operations phase of the mission since most of the team 
remained the same. The operations team was able to 
respond to anomalies quicker and were better prepared to 
handle anomaly situations. The seamless transition of the 
operations team from I&T to on-orbit operations played a 
key role in anomaly investigations, as well as recovery 
operations. 

Experience has enabled the operations team to become part 
of the spacecraft development team. By being part of the 
spacecraft development team, the operations team helped 
develop realistic operational testing scenarios, refine 
spacecraft design, and bridge the gap between the spacecraft 
and ground development teams. The operations team often 
assisted the system engineers in developing spacecraft test 
with operational scenarios. This allowed the spacecraft to 
be tested in the way that it would be operated on-orbit. As 
the operations team gained experience and knowledge, they 
helped refine spacecraft design by providing inputs and 
comments on flight software requirements and functions. 
These inputs were requested to help reduce the complexity 
of the operation concepts and with developing ground 
automation. For example, on the Triana mission, the C&DH 
software group changed the stored command processor 
design from previous SMEX missions. The operations team 
played a key role in reviewing design requirements and 
testing. This not only helped the software developers but 
gave the operations team valuable insight into the 
functionality of the software. By including the operations 
team in development, overall operational risk was reduced. 


Overall operational risk was also reduced because 




operational procedures and timelines were tested earlier, 
before major simulations and tests. This led to higher 
quality simulations and training for the entire project. 

Other operational concepts were verified earlier such as 
trending. The operations team developed methods to test 
various ground components earlier. The result was 
increased test time for those components which would have 
otherwise been tested only during simulations and tests. 

4. Consolidated Test Team 

The ground system testing approach for the first three 
SMEX missions follow the traditional method used for most 
if not all GSFC ground systems in the 1980s. The 
development team delivered software to an independent 
system test team. This group was primarily responsible for 
requirements testing. Software anomalies or failures were 
documented using a problem reporting system specific to the 
system test group. Upon completion of system testing, the 
software element was delivered to a second independent test 
team that was responsible for acceptance testing. The 
primary responsibility of this group was to determine the 
ground system element’s ability to support the operations 
environment. Another problem reporting system was used to 
track software anomalies detected in this phase. Upon 
completion of acceptance testing, the software was delivered 
to the operations environment. At this stage, the mission 
readiness manager and his team executed interface tests with 
all the ground system elements including the spacecraft, 
ground stations and the science team’s home facilities. 
Again, a separate problem reporting system was used to 
track anomalies. In addition, each one of these groups had a 
separate test plan and procedures document with different 
test goals. The result of this testing approach was a thorough 
testing of the ground system but with a cost and schedule 
impact that was at odds with the faster, better, cheaper 
theme of SMEX missions. 

With the selection of the second set of SMEX missions and 
launch delays for two of the original missions, a new process 
was needed to mitigate the risk of tighter schedules and 
overlapping mission activities. The new approach took 
advantage of the selection of ITOS as the operational 
command and control system and the larger amount of reuse 
enjoyed by the SMEX ground systems. 

The new approach [3] adopted for the TRACE and WIRE 
missions consisted of the following 

• unify the three test groups into one consolidated test 
team led by the mission readiness manager 

• create a single test plan and procedures document which 
addressed the objectives of each of the three test groups 

• make the most efficient use of tests by merging test 
objectives and eliminating redundancy 

• consolidate the test reporting mechanism to one system 
used by all test members 


• reduce the overall test group size but augmented the 
team with support from operations personnel 

The results of the consolidated test approach for the TRACE 
mission when compared to the previous SMEX missions 
were significant. A 4-to-l reduction in the test schedule was 
achieved while reducing the test team size by 50%. 

The ability of the consolidated test team to respond quickly 
and efficiently to ground system software patches and 
critical fixes became crucial in the later, hectic part of the 
SMEX Project at GSFC. The test team’s rapid response to 
conflicting demands of the SMEX missions was a key factor 
in the successful support of three separate launches. 

5. Reuse of Spacecraft, Systems & People 

Because each SMEX mission had a development cycle of 
approximately three-years from mission selection to launch, 
both the space-based and ground-based systems had to 
perform requirements development, system design, 
implementation, test and operations certification within this 
envelope. The quick access and rapid deployment resulted 
in modifications to the existing paradigms for both space- 
and ground-based hardware fabrication and software 
development. The major emphasis was in the following 
areas: 

• Common spacecraft architecture including similar or 
identical sensors, actuators and hardware components 

• Reuse of flight- and ground-based software 

• Better, more efficient use of personnel 

Common spacecraft architecture 

A major change to the spacecraft architecture was a common 
spacecraft bus used on the first SMEX missions and for the 
Triana mission. The Triana hardware architecture has a 
heritage from the earlier SMEX satellites and specifically 
the SMEX-Lite. This approach reduces spacecraft design 
and test engineering, development team size, flight hardware 
costs, and the cost of flight operations. This common bus 
approach also maintains mission reliability and improves 
performance over previous SMEX missions. The SMEX- 
Lite has "plug-and-play" architecture that allows 
components to be added or deleted from the system with 
virtually no redesign and without disturbing other 
subsystems. Functions are segregated into "slices" that are 
independent at the subsystem level. The "plug-and-play" 
concept was extended to the electronics, sensors, actuators, 
software, solar arrays, the mechanical system, and the 
ground support I&T system. 

Reuse of flight-based and ground-based subsystems 

The Triana flight software enjoys a significant degree of 
heritage from previous SMEX missions. Its architecture 
utilizes modular design techniques that maximize software 
reuse. This approach provides flexibility for tailoring the 


system to unique mission requirements and improves the 
overall reliability of the flight code. 

By using this standard set of hardware and software systems, 
the spacecraft development, fabrication, and certification 
time has been reduced to fit with the three-year lifecycle of 
mission selection to launch. Some upgrades were made to 
both the spacecraft hardware and software simply based on 
upgrading a component that was out-of-date. 

An exceptionally important change for TRACE from 
previous SMEX missions was the merging of the I&T 
system that was used for previous SMEX satellites with the 
independently developed mission operations system. In 
addition to the reduced software development costs, the 
new, combined ITOS system allowed display pages and 
procedures prepared by the FOT during the I&T phase to 
also be used during the operational phase, resulting in great 
time and cost efficiencies for the FOT. The next SMEX 
mission, WIRE, used the same system for the I&T and the 
operational phases. Also during this same time, the SWAS 
mission, which had its launch delayed until 1999, 
reengineered its GDS to use the same system. These three 
missions were launched and supported using the identical 
command and control system (ITOS) within eleven months 
of each other. As shown in Table 1, the SMEX software 
and hardware components of the GDS have been carried 
over into the Triana GDS. The one modification was the 
result of a spacecraft change related to how on-board 
commands are stored. Previously, the SMEX missions 
supported command buffers, which were used to store an 
absolute or relative time sequenced command or series of 
commands. With the advent of SMEX-Lite and the 
migration to the Triana mission, the on-board buffers were 
replaced with command tasks that are managed by the on- 
board command and data handling (C&DH) subsystem. In 
this instance, the GDS minimized the risk by using the exact 
same command translator that is being developed by the 
spacecraft development team. The GDS did not develop its 
own separate system to perform the identical function. 

Other GDS modifications for Triana are to support the 
updated telemetry and command mnemonics, as well as the 
file management concepts to support VxWorks (on-board 
and ground processed file management). 

Additionally, the GDS is reusing to the extent possible any 
hardware systems that were used by the previous SMEX 
missions. When practical, the Triana program will purchase 
newer hardware components to upgrade to the latest 
hardware and operating systems or to purchase a faster, 
more powerful version of a similar hardware platform. 


The SMEX missions and Triana are able to use the same 
suite of hardware to support a launch. By using this same 
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Table 1. Comparison of GDS elements between earlier 
SMEX missions and Triana 


set of hardware, the missions have eliminated risks 
associated with moving to completely new platforms. Since 
this hardware suite has supported previous launches, the 
GDS and operations team know that these components have 
passed the stress tests associated with supporting a launch; 
there are no unknowns by using the existing suite. 

Reuse of personnel from project, operations and mission 
teams 

Initially, the SMEX Project started with a large-scale army 
of subsystem developers, independent of each other, only 
meeting during reviews to consolidate interfaces and 
specific work issues. This was the approach used during the 
SAMPEX mission. 

The SMEX Project then migrated to a combined System 
Implementation Team (SIT) approach that coordinated GDS 
development but was still independent and lagged behind 
the project spacecraft integration. The SWAS and FAST 
missions used this combined SIT approach. This approach 
helped to minimize the problems encountered during earlier 
GSFC programs, but did not completely solve the problems 
related to mission development and interfacing with the 
project and science teams. 

Eventually, the SMEX Project (for the TRACE and WIRE 
missions) evolved into an Integrated Product Development 
Team (IPDT) that coordinated the development, project, and 
test groups. This IPDT took the form of the mission team 
(MT) and provided a sub-group related to mission readiness 
testing (MRT). The mission team also provided support to 
the project for meetings and reviews. The TRACE mission 
was first to use an IPDT [2]. The concept of an IPDT is not 
a new idea. However, the formation of the TRACE IPDT 
stressed joint development and partnering between 
previously independent development groups, breaking 
through traditional organizational barriers. A very 
significant portion of the cost to the previous mission was 
spent on communication via thick, formal documents. The 





TRACE IPDT minimized these costs by removing the 
formal barriers that required the generation of the 
documentation and concentrating on personal interaction 
and the use of the Internet as a repository for information 
sharing. Additionally, the flight operations team had ready 
access to all documentation regardless of where a particular 
operational workstation or laptop was located. By 
combining the workforce into the IPDT, any potential cost 
or schedule problems were mitigated because the standard 
organizational barriers were broken. By overcoming 
organizational barriers, the IPDT was able to define and 
own the process that allowed the TRACE and WIRE 
missions to reduce or eliminate duplication of effort. This 
same approach is currently in place on Triana. 

As with the last two SMEX missions, the Triana mission 
works to minimize the differences between project personnel 
and CDS development and operations personnel. GDS and 
operations teams have supported the project reviews and 
weekly status briefings; operations personnel have also 
provided pre-launch spacecraft integration testing. The GDS 
and operations team used this information exchange to learn 
the nominal spacecraft operation concepts. By supporting 
the Project during reviews and weekly discussions, the GDS 
and operations teams have reduced development time and 
costs to meet the 3-year mission selection to launch criteria 
implicit in the SMEX and Triana charters. 

While a major risk mitigation technique is to reuse the 
mission personnel and GDS HW and SW components, this 
is not to say that people do not move on to other programs 
or career opportunities. Nor does it mean that software 
systems used in supporting the first SMEX mission, 
SAMPEX, are being prepared for use on Triana. On the 
contrary, no software used for the SAMPEX launch in 1992 
will be used for Triana. In fact, SAMPEX has undergone a 
“technological upgrade” benefiting from the improvements 
made during the course of the SMEX program and was 
retrofitted while on-orbit and collecting valuable science 
data. Likewise, a core group of engineers remain on Triana 
that were associated with SAMPEX but a significant number 
of personnel have moved onto other projects. 

Bringing new team members “up to speed” on the next 
mission has been smooth and very successful because all 
documentation and review materials can be found on-line. 
This allows the new personnel to readily review the mission 
requirements, concepts, and processes. 

Because the SMEX project was a series of similar 
spacecraft, once on-orbit the spacecraft were available for 
limited use in testing automation concepts and the on-orbit 
mission was used to train future operations staff. In fact, the 
TRACE and WIRE missions paved the way for the current 
autonomous operations concepts and allowed the formation 
of a standard 8x5 operations group. While the Triana 
spacecraft will be constantly in view of a ground station and 
supply a 24-hour live feed to the Triana control center; the 


Triana operations team only will provide normal operations 
support during the standard day shift. However, during the 
launch and checkout phase, the control center will be staffed 
to provide 24x7 support for commanding and monitoring of 
the spacecraft instrument and subsystems. 

In addition to the on-orbit spacecraft providing the basis for 
autonomous operation concepts, the operations personnel 
can be trained on these missions because of the 
similar/identical systems that will be used on the next 
generation mission. The experience and confidence gained is 
a significant risk mitigation technique for the operations 
team of the follow-on mission. 

4. Conclusions 

Although the first SMEX was launched on schedule in July 
1992, the remaining spacecraft experienced significant 
delays due to launch vehicle problems. FAST was finally 
launched in August 1996. Because of these launch delays 
and the change to an ITOS-based architecture for mission 
set 2, it was decided in the fall of 1997 to re-engineer the 
SWAS GDS with the TRACE/WIRE approach. As a result 
the SMEX GDS mission team was supporting three missions 
simultaneously in different stages of development. It was a 
challenging task for the GDS mission team. However team 
members recognized the benefits of operating missions with 
the ITOS architecture. Figure 4 illustrates the revised 
schedules and subsequent launches of these three satellites. 

Subsequently, the TRACE, SWAS and WIRE spacecraft 
were all launched within an 11 -month interval. TRACE in 
April 1998, SWAS in December 1998 and WIRE in March 
1999. The GDS and operations team performed extremely 
well for all the launches and on-orbit operations. Although 
WTRE experienced a severe on-board anomaly, scientific 
studies were performed using its sensitive star tracker. 
Today, 8 years after the first SMEX launch, all five 
spacecraft are operating and returning scientific and 
engineering data with the GDS achieving a cumulative data 
return of nearly 99%. 
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